Chris Huff wrote:
> 
> In article <38CDD5B5.36C4EB94@ij.net>, Matt Giwer <jul### [at] ijnet>
> wrote:
> 
> > Chris Huff wrote:
> >
> >       Pardon for deleting all of yours but this is my issue.
> >
> >       If syntax is extended then those issues will have to be
> > addressed. That is my point.
> 
> What issues? That is what I want you to clarify.

	Will do. 

>     The for loop is well defined, POV would use the existing definition,
> which is quite possible with the POV syntax.

for i = 1 to 5

stuff(variables used elsewhere)

next i

	Is i ?= 5 evaluated before or after stuff? If before stuff is
evaluated 5 times. If after stuff is evaluated 6 times. In the
latter case the stuff variables have the value of i = 6. 

	But if the syntax is

for i = 1 to 5 inc 1 

stuff

#endfor

	pre-evaluation is implied but still may not be implemented that
way. 

	If you are writing the parser you have to decide these things
and document them. And you have to set up a tokenized first pass
that finds the next i (and bails out on i=5) rather than waiting
for it. If you wait for it you have to store the current and
previous stuff and when finding i = 5 throw away the current and
copy previous to the variables or some scheme like that. 

>     There is no debate that I have seen over integer versus float
> variables within a loop, and that is irrelevant anyway, since POV
> doesn't have separate types for integer and float.

	The lack of typing is a weakness that C folks love. (I will get
around to testing it some day but I think I have seen a problem
with #decare i = 1 and #declare i = 1.0 that has solved a loop
problem. I won't swear to it.) But if all variables are
automatically signed four bytes then it is not an efficient
engine. 

>     The ++ and -- operators would not fit in the current syntax of POV,
> so you can forget about them.

	I have no problem with those than inc and dec. But is it going
to be int + 1 or float + 1? But since it is not a typed language
again all the clarity of C and Forth is possible. 

> > One simple routine that can do everything is quite good enough.

> So we should drop the #switch, #macro, and #while features and add #goto
> and #label? And get rid of #local while we are at it...

	There is an old saying, "All things are simple to those who do
not have to do it themselves." I am of the KISS school. 

	#local is required when folks jump out of loops and such.
Therefore it is a good option to have. But if folks just do a bit
of extra typing there i1 i2 i3 i4 there is no need for it. 

	Most of my issue has been on alternatives to #while. I gave an
example on for ... next as opposed to while. If the answer to for
... next is to make it behave the same was while, why is there a
need for for ... next? 

	There is an issue of clarity. Clarity to who? To the author?
Clarity and familiarity are identical. 

	Clarity to others? Axiom of programming. Uncommented code is
unclear to others. Axiom the second. Commented code is likely
unclear to others. 

-- 
A free internet for a free people.

Post a reply to this message